home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 4
/
QRZ Ham Radio Callsign Database - Volume 4.iso
/
files
/
packet
/
misc
/
netconf.arc
/
AARP.TXT
< prev
next >
Wrap
Text File
|
1988-12-10
|
16KB
|
322 lines
Thoughts on the Issues of Address Resolution and
Routing
in Amateur Packet Radio TCP/IP Networks
Bdale Garbee, N3EUA
_A_B_S_T_R_A_C_T
The current KA9Q software includes a technique
for automatic address resolution, but does not include
automatic routing features. The difference between
routing and address resolution is explained, and
several concerns for on-air automatic routing algo-
rithm implementations are mentioned.
_B_a_c_k_g_r_o_u_n_d:
One of the major goals of those involved in the TCP/IP project
begun by Phil Karn KA9Q has been to develop a network implemen-
tation that automatically handles routing. By this, we mean
that it should not be necessary for an end user to have any
knowledge of the topology of the network he is using in order to
perform normal ``day-to-day'' network activities. The user's
involvement should extend only to requests of the form ``get
file from host <n>'' or ``send mail to user <n> at host <m>''.
Several groups are currently working on software that implements
one or another form of automatic routing. The NET/ROM product
requires that the user only know the nearest NET/ROM site to
both the originating and destination stations in order to estab-
lish a circuit between the two. The TEXNet system reportedly
handles traffic between its endnodes in a similarly transparent
fashion. But in both of these cases, the user must still be
aware of some aspects of the network topology above and beyond
knowing the hostname of the destination site.
What we have right now _i_s_n'_t _g_o_o_d _e_n_o_u_g_h!
_A_R_P, _t_h_e _A_d_d_r_e_s_s _R_e_s_o_l_u_t_i_o_n _P_r_o_t_o_c_o_l:
In his TCP/IP package, Phil Karn has included an implementation
of the ARP Address Resolution Protocol, which was originally
created to allow for automatic mapping of 32-bit IP addresses
into 48-bit Ethernet addresses on a local wired subnet. ARP
works by having the originating station issue an ``ARP Request''
whenever it wishes to converse with a host whose IP address is
known, but whose ``physical address'' is unknown. An important
December 6, 1988
thing to remember about ARP is that it was designed for subnets
where all hosts can hear each other directly.
In the Amateur Packet world, the physical address is equivalent
to the destination station's callsign and optional sub-station
identifier, or SSID. If and when the destination station hears
the broadcasted request, it knows the IP address and physical
address of the sending station by examining the contents of the
request packet, and it responds by sending an ``ARP Reply''
packet directly to the originating station.
The value of ARP is that the only piece of information about a
station that you need to know ahead of time in order to make
contact with them is their IP address, as long as they are
within RF range. ARP performs very well at the task it was
designed for, which is simple mapping of logical address into
physical address.
_T_h_e _S_t_a_t_e _o_f _R_o_u_t_i_n_g:
There are two simple situations that demonstrate the limitations
of ARP, and will serve to distinguish address resolution from
routing. Let us consider the IP Switch, and the Digipeater.
A digipeater is a device that receives a packet that has been
source routed through it, and echoes that same packet on the
same or a different channel, changing the packet only by marking
it as ``having been digipeated by this site''. Our interest in
digipeaters stems only from their current popularity, and
resulting availability. In order to make use of a digipeater
with the KA9Q Internet software, both the source and destination
stations need to explicitly provide the physical ``digipeater
string'' information to the NET.EXE package, as ARP is totally
unaware of the existence of digipeaters. This is not good.
Several extensions to ARP have been proposed, but a better solu-
tion than extending ARP may be to manual routing of digipeaters
for IP, and rely on IP Switches and/or other ``level three''
network implementations to make the subnet appear to be contigu-
ous.
An IP Switch in a certain sense performs the same function as a
digipeater from the end-user viewpoint. The Switch receives
packets that are destined for other hosts, and forwards them via
one of perhaps several channels. For those familiar with Ether-
net or other wired networks running TCP/IP, an IP Switch in the
Packet Radio environment differs from an IP Gateway primarily in
that a Switch may want to retransmit a packet on the same chan-
nel it heard it on, while a Gateway would never want to do that.
The fundamental difference between a digipeater and a Switch is
that a Switch makes routing decisions, while a digipeater
depends on the end user to source-route a connection through it.
Address resolution therefore is the mapping of a ``network
address'', such as an IP address in the TCP/IP environment, into
an actual physical station identifier, such as a TNC callsign.
December 6, 1988
Routing is the set of issues and algorithms that surround pass-
ing packets through intermediate stations.
_T_h_o_u_g_h_t_s _A_b_o_u_t _W_h_a_t _W_e _N_e_e_d:
Routing individual datagrams is currently handled by manually
inserting entries into a station's ``route table'' that tell the
software to route all packet for a given subrange of IP
addresses via a specified gateway, or switch. This is already a
very powerful mechanism, in that a user can specify his default
routing to be via his local switch, and then add special cases
to ``un-default'' local stations he can hit directly, and the
end user problem is therefore greatly reduced.
But the IP Switches currently run the same software. The only
way to build a network is to manually create routing entries at
each switch. We need to develop an algorithm for automatically
determining reasonable paths, that can automatically update the
routing tables at each Switch site. There are two different
philosophies about how to do this. One is based on the idea
that the network should ``already know'' what to do with each
packet when it arrives at a given switch location, the other is
based on the idea that someone requesting a connection to a site
that is not known locally generates by their request the initia-
tive for the network to go figure out how to get there.
The tradeoff at the highest level is simple. The first mechan-
ism forces the network to continuously be passing information
about routes between switches, all of which is network overhead.
The second mechanism generates a great deal of traffic on the
first request for a path segment that does not currently exist
in the routing tables, but probably has a lower overhead
overall. It does, however, cause a much greater ``turnaround
time'' delay for the user requesting an unusual route. What the
best solution to this tradeoff between overhead and individual
user performance is has not in my opinion been sufficiently con-
sidered.
A final thought for this paper is that we need to be able to
handle mobile stations, not just stations that are away from
their home switches, but stations that are actually in motion.
This probably cannot be done by schemes that dynamically reas-
sign IP addresses for the simple reason that a station might
have a connection in progress when it crosses a switch boundary.
Food for thought.
_R_e_l_a_t_e_d _I_s_s_u_e_s:
There are two other issues that need to be considered. One is
the mapping of mnemonic hostnames into IP addresses, both for
clients like FTP and Telnet, and for Mail transfer. Secondly,
there is a separate but similar routing problem that exists in
the mail handling portion of the network software, in that a
given node may have more than one mail transport system avail-
able to it (including perhaps things like uucp and Fidomail),
December 6, 1988
and must make a ``routing decision'' as to which delivery agent
should be called to process a given message.
The current means of handling the mapping of mnemonic hostnames
into IP addresses is to maintain a file listing the possible
translations that are known to the system, and requiring the
user to specify the IP address directly when a host entry cannot
be matched. A much better system would be to designate a host-
name server in each local subnet, and have the client software
negotiate with the name server to map a hostname into an
address. This reduces by far the number of locations that must
maintain a full hostname database. Cacheing of some number of
most recently or frequently used addresses on the local machine
should minimize the impact of name-serving on the network's
overall performance.
Mail routing is a fascinating topic, but one which deserves much
more room than that which is available here. Suffice to say
that the problem of mapping a given mail message into an
appropriate delivery agent on a given mail-handling host can be
as simple or as complicated as routing packets at a packet
switch.
_W_r_o_n_g _T_h_i_n_g_s _W_e _C_o_u_l_d _D_o:
With amazing regularity, well-meaning hams have suggested a
variety of schemes for ``routing'' packets based on everything
from grid squares to zip codes, to telephone exchange prefixes.
The fundamental problem with this is that _t_h_e_r_e _i_s _n_o _r_e_l_a_t_i_o_n
_b_e_t_w_e_e_n _a _h_o_s_t'_s _n_a_m_e _o_r _a_d_d_r_e_s_s _a_n_d _w_h_a_t _i_s _t_h_e _b_e_s_t _p_a_t_h _t_o
_t_a_k_e _t_o _r_e_a_c_h _t_h_a_t _h_o_s_t. A classic example is the satellite
``wormhole'' between CA and MD, which often means that to get
from the midwest to the east coast, the best path would be to go
west, _n_o_t _e_a_s_t, to the wormhole end, and tunnel across country.
We need to design automatic routing mechanisms that do not rely
on host names or network addresses. We can use names and
addresses as hints, but cannot expect them to always work, par-
ticularly given the mobile nature of the modern ham! Routing
depends on a network's topology, not the geography or political
boundaries that it crosses. Any routing mechanism that we adopt
_m_u_s_t handle mobile stations as well, which is virtually impossi-
ble when the routing mechanism is based on some fixed geographi-
cal reference system.
Another interesting proposal has been to not assign fixed IP
addresses to individual stations. There are some schemes for
dynamically assigning addresses to small hosts in use in major
universities, but I am not yet convinced that this is a good
thing to do on packet, primarily because our environment poses
some additional complications over those present in the wired
university environment. The most obvious of which is the mobile
station, which might have a connection in progress as it crosses
an address allocation zone. None of the existing schemes that I
am aware of allow for mobile stations. We should, however, keep
December 6, 1988
an eye on progress in this direction outside of amateur radio,
in case someone makes it work.
_C_o_n_c_l_u_s_i_o_n:
The purpose of this paper has been to document some goals for
those implementing routing mechanisms for packet radio, and to
raise some specific concerns that should be understood and con-
sidered. Much work remains to be done. Many of the ideas dis-
cussed here are under consideration by the group of people work-
ing with the KA9Q Internet software, and undoubtedly we will
eventually see an automatic routing implementation either as
part of the package, or adopted from a third-party source's
level three implementation.
_R_e_f_e_r_e_n_c_e_s:
1. Tanenbaum, A.S., ``Computer Networks'', Prentice-Hall,
1981.
2. RFC826, Address Resolution Protocol.
3. Beattie, J.G., ``Proposal: Recommendation AX.121NA Number-
ing Plan For The Amateur Radio Network in North America'',
_F_o_u_r_t_h _A_R_R_L _A_m_a_t_e_u_r _R_a_d_i_o _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e,
1984.
4. Beattie, J.G., ``Proposal: Recommendation AX.121 Interna-
tional Numbering Plan For The Amateur Radio Network'',
_F_i_f_t_h _A_R_R_L _A_m_a_t_e_u_r _R_a_d_i_o _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e,
1986.
5. Fox, Terry, ``Amateur Network Addressing and Routing'',
_F_i_f_t_h _A_R_R_L _A_m_a_t_e_u_r _R_a_d_i_o _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e,
1986.
6. NET/ROM Beta-Test Preliminary Documentation, Software 2000
Inc.
7. TEXNet Presentation at the 1987 TAPR Annual Meeting.
December 6, 1988
